I. Abstract
This OGC® IndoorGML standard specifies an open data model for indoor information in UML and technical implementation schemas in GML, SQL and JSON. While there are several 3D building modeling standards such as CityGML, KML, IFC, LADM and IMDF which deal with interiors of buildings from geometric, cartographic, and semantic viewpoints, IndoorGML focuses on modeling indoor spaces and their neighbourhood relationships to support indoor location-based services. This version of IndoorGML addresses spaces and networks for indoor navigation.
II. Keywords
The following are keywords to be used by search engines and document catalogues.
ogcdoc, ogc documents, indoor, navigation, indoorgml, gml, sql, json
III. Preface
The goal of IndoorGML is to represent and allow for exchange of geoinformation that is required to build and operate systems that rely on spaces and topological relationships between them such as path computation, sensor coverage, property accessibility, etc. Several standards such as CityGML (OGC, 2012), KML (OGC, 2015), LADM (ISO, 2012) and IFC (ISO,2018) have been published to describe 3D geometry and semantics of building features, but they are not readily appropriate to derive spaces and their topological relationships. The navigation standard IMDF (OGC, 2021) provide a comprehensive model to compute path between features located on a map, but the derived network is application specific. This standard aims to provide unified, standardised and flexible approach for indoor spatial information required for space-graph based applications such as indoor navigation.
This version of the OGC standard consists of two components: 1) a core data model to describe topological connectivity and different contexts of indoor space, and 2) a data model for navigation in indoor space.
This version of IndoorGML covers geometric and semantic properties of indoor spaces relevant for indoor navigation. These indoor spaces may differ from the spaces described by other standards such as CityGML, KML, IFC, LADM and IMDF. In this respect, IndoorGML is a complementary standard to CityGML, KML, IFC, LADM and IMDF to support location-based services for indoor navigation.
IV. Security Considerations
No security considerations have been made for this Standard.
V. Submitting Organizations
The following organizations submitted this Document to the Open Geospatial Consortium (OGC):
- The University of New South Wales
- Pusan National University
- Ordnance Survey
- University of Seoul
- All4Land
- Delft University of Technology
- National Institute of Advanced Industrial Science and Technology
VI. Submitters
All questions regarding this submission should be directed to the editor or the submitters:
| Name | Affiliation | Contact |
|---|---|---|
| Sisi Zlatanova | University of New South Wales | s.zlatanova at unsw.edu.au |
| Ki-Joune Li | Pusan National University | lik at pnu.edu |
| Abdoulaye Diakite | The University of New South Wales | diakite.abdoulaye at gmail.com |
| Taehoon Kim | National Institute of Advanced Industrial Science and Technology | kim.taehoon at aist.go.jp |
| Jeremy Morley | Ordnance Survey | Jeremy.Morley at os.uk |
OGC IndoorGML 2.0 Part I – Conceptual Model
1. Scope
NOTE: IndoorGML is an OGC® standard for the representation and exchange of indoor navigation network models. IndoorGML is a UML conceptual schema and implementation schema of the Geography Markup Language version 3.2.1.
This version of IndoorGML establishes a common schema for indoor navigation applications. It models topology and semantics of indoor spaces, which are needed for the components of navigation networks. IndoorGML contains a minimum set of generic, unified modelling concepts for indoor environments as follows:
Spaces and space subdivision contexts;
Geometric and semantic properties of spaces;
Types of connectivity between spaces;
Navigation networks (logical and metric) and their relationships.
2. Conformance
Conformance targets of this OGC® Standard are IndoorGML instance documents. Conformance with this standard shall be checked whether IndoorGML instance documents achieve the criteria as defined in clause 7 to 9.
In order to conform to IndoorGML, and schema document should:
conform to the rules, specifications, and requirements in clauses 7 to 9; and
pass all relevant test cases of the abstract test suite given in Annex A.
The framework, concepts, and methodology for testing, and the criteria to be achieved to claim conformance are specified in the OGC Compliance Testing Policies and Procedures and the OGC Compliance Testing website.
3. Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
ISO: ISO 8601-1, Date and time. International Organization for Standardization, Geneva https://www.iso.org/standard/70907.html.
ISO: ISO 19103, Geographic information. International Organization for Standardization, Geneva https://www.iso.org/standard/56734.html.
ISO: ISO 19105, Geographic information. International Organization for Standardization, Geneva https://www.iso.org/standard/76457.html.
ISO: ISO 19107, Geographic information. International Organization for Standardization, Geneva https://www.iso.org/standard/66175.html.
ISO: ISO 19109, Geographic information. International Organization for Standardization, Geneva https://www.iso.org/standard/59193.html.
ISO: ISO 19110, Geographic information. International Organization for Standardization, Geneva https://www.iso.org/standard/57303.html.
ISO: ISO 19111, Geographic information. International Organization for Standardization, Geneva https://www.iso.org/standard/74039.html.
ISO: ISO 19115-1, Geographic information. International Organization for Standardization, Geneva https://www.iso.org/standard/53798.html.
ISO: ISO 19136-1, Geographic information. International Organization for Standardization, Geneva https://www.iso.org/standard/75676.html.
ISO: ISO/TS 19139-1, Geographic information. International Organization for Standardization, Geneva https://www.iso.org/standard/67253.html.
Cliff Kottman: OGC 99-108r2, Topic 8 — Relationships Between Features. Open Geospatial Consortium (1999).
Cliff Kottman: OGC 99-110, Topic 10 — Feature Collections. Open Geospatial Consortium (1999).
Clemens Portele: OGC 07-036, OpenGIS Geography Markup Language (GML) Encoding Standard. Open Geospatial Consortium (2007).
Cliff Kottman and Carl Reed: OGC 08-126, Topic 5 — Features. Open Geospatial Consortium (2009).
4. Terms and definitions
This document uses the terms defined in OGC Policy Directive 49, which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this document and OGC documents do not use the equivalent phrases in the ISO/IEC Directives, Part 2.
This document also uses terms defined in the OGC Standard for Modular specifications (OGC 08-131r3), also known as the ‘ModSpec’. The definitions of terms such as standard, specification, requirement, and conformance test are provided in the ModSpec.
For the purposes of this document, the following additional terms and definitions apply.
4.1. Indoor Space
A space within one or multiple buildings.
4.2. Cellular Space
A cellular space S is a set of identifiable sells ci grouped according to theme T and is noted ST is ST = {c1, c2, …, cn}
4.3. Graph
A graph G (V, E) where V is a set of nodes representing cells and E is the set of edges indicating topological relationships.
4.4. Adjacency Graph
A graph Gadj (V, Eadj) where V is a set of nodes representing cells and Eadj is the set of edges indicating the adjacency relationship.
4.5. Connectivity Graph
A graph Gcon(V, Econ) where V is a set of nodes representing cells in indoor space and Econ is the set of edges indicating the connectivity relationship.
4.6. Logical Network
A graph G (V, E), where node v in V and edge e in E do not contain any geometric properties.
4.7. Geometric Network
A graph G (V, E) where node v in V and edge e in E contain both geometric properties.
4.8. Multi-Layered Space Model
A model representing multiple themes of cellular spaces and/or graphs and inter-layer connections between them.
5. Conventions
This sections provides details and examples for any conventions used in the document. Examples of conventions are symbols, abbreviations, use of XML schema, or special notes regarding how to read the document.
5.1. Symbols (and abbreviated terms)
The following symbols and abbreviated are used in this standard.
Table 1 — Symbols and abbreviated terms
| Abbreviation | Word or Phrase |
|---|---|
| BIM | Building Information Modeling |
| CityGML | City Geographic Markup Language |
| GPS | Global Positioning Systems |
| CRS | Coordinate Reference System |
| GML | Geographic Markup Language |
| IndoorGML | Indoor Geographic Markup Language |
| IFC | Industry Foundation Classes |
| ISO | International Organization for Standardization |
| KML | Keyhole Markup Language |
| LOD | Level of Detail |
| MLSM | Multi-Layered Space Model |
| OGC | Open Geospatial Consortium |
| RFID | Radio Frequency IDentifier |
| UML | Unified Modeling Language |
| XML | eXtended Markup Language |
| 1D | One Dimensional |
| 2D | Two Dimensional |
| 3D | Three Dimensional |
5.2. UML Notation
The diagrams that appear in this standard are presented using the Unified Modeling Language (UML) static structure diagram. The UML notations used in this standard are described in the diagram below.
Figure 1 — UML Notations
In this standard, the following three stereotypes of UML classes are used.
<<Interface>> A definition of a set of operations that is supported by objects having this interface. An Interface class cannot contain any attributes.
<<DataType>> A descriptor of a set of values that lack identity (independent existence and the possibility of side effects). A DataType is a class with no operations whose primary purpose is to hold the information.
<<CodeList>> is a flexible enumeration that uses string values for expressing a list of potential values.
In this standard, the following standard data types are used:
CharacterString – A sequence of characters;
Boolean – A binary value of either 1 (true) or 0 (false);
Integer – An integer number;
Double – A double precision floating point number; and
Float – A single precision floating point number.
5.3. Identifiers
The normative provisions in this standard are denoted by the URI
http://www.opengis.net/spec/indoorgml/2.0
All requirements and conformance tests that appear in this document are denoted by partial URIs which are relative to this base.
6. Overview of IndoorGML
IndoorGML has been designed to support applications developers in providing Location-based services applications. Figure 2 illustrates the place of IndoorGML in the ecosystem of standards, models and files formats and end-user applications. IndoorGML provides simplified yet standardized notations for indoor spaces and networks, which can be used in different application contexts such as navigation, monitoring, asset and property management. IndoorGML can be linked to and derived from any geometric model that a building owner may have (floor plans, CAD models, BIM models, laser scans, measurements). The semantics notations of IndoorGML are generic and therefore allowing to protect some sensitive building information.
Figure 2 — IndoorGML in the overall application development ecosystem
6.1. Motivation for defining IndoorGML
Indoor environments differ from outdoor in many aspects. The indoor spaces have less structures lanes and directions to move; they are multi-levelled and reachable via different vertical connectors such as stairs, elevators, escalators, and ramps; they have large number of obstacles such as furniture columns, fences, decorations. The spaces are enclosed and accessible via different types of openings (normal doors, emergency doors, sliding doors, one-way doors, portals). The height of the indoor spaces might vary to such extend that some spaces become not accessible for certain type of users. This has led to the existence of variety of approaches for modeling indoor environments and providing services. Therefore, well-known concepts, data models, and standards need to the be refined and unified to reflect specifics of indoor environments.
In general, indoor spatial information can be classified into two large categories as follows:
Architectural components (walls, stairs, slabs) and interior facilities (furniture).
Cavities (rooms and corridors) or virtual subdivision (sensors coverage and legal spaces)
Building and facility management application require mostly information from the first category. Indoor location-based services (LBS), indoor route analysis or indoor geo-tagging services require mostly information from the second category.
IndoorGML is intended provide a unified modeling approach that is necessary to support indoor applications using information from those two categories. The leading concepts in IndoorGML are the Indoor spaces and the topological relationships between them (Clause 7.1), which are grounded in the Poincaré duality. The space notations are kept as generic as possible to reflect the variety and complexity of indoor environments. The entire indoor environment — objects and spaces — constitutes the Cellular space (Clause 7.2). Cells have attributes, one of which is their geometry. The cell units can be subdivided or aggregated (Clause 7.2). The Cell Spaces are the basis for deriving an adjacency/connectivity/accessibility network (Clause 7.3). Cell Spaces of the same characteristics are non-overlapping and form a thematic layer (Clause 7.6). For example, architectural components (walls, slabs, stairs) and the corresponding cavities (rooms, corridors) form a Topographic thematic layer.
IndoorGML 2.0 follows a model-driven approach. All concepts are organised in a UML class diagram (Clause 8), from which the implementation schemas for GML is provided (Annex A).
6.2. Modularisation
Following the guidance in the OGC’s policy (OGC, The Specification Model – A Standard for Modular specifications, 2009), IndoorGML is organised into a Core module and Extension modules that have mandatory dependency on the core (see Figure 3). The IndoorGML core module comprises the basic concept and each extension module covers a specific application, which requires extension of the core module semantics. IndoorGML 2.0 contains one extension named Navigation. Each IndoorGML module is specified by an implementation schema definition (XML, SQL, and JSON).
The dependency relationships among IndoorGML’s modules are illustrated in Figure 3. Each module is represented by a package in UML. The package name corresponds to the module name. A dash arrow in the figure indicates that the schema at the tail of the arrow depends upon the schema at the head of the arrow. In the following sections the modules are described in detail.
Figure 3 — Modular organisation of IndoorGML
7. General Concepts of IndoorGML
IndoorGML is a space-centred standard. As so, it focuses on the three main types of information of spaces (2D or 3D): geometry, topology and semantic. In order to define the space and its suitable properties under the consideration of those three types of information, the standard relies on the following concepts:
Cellular space,
Poincaré Duality,
Semantic extension,
Thematic layering.
The cellular space provides the geometric description of an IndoorGML model. The Poincaré duality describes the topological relations such as adjacency and connectivity between the spaces. Together, they form the key concept of Primal-Dual model that defines the core part of an IndoorGML model. The semantic extension mechanism, as its name suggests, allows to add more details to the basic semantics of the core module. Thematic layering mechanism allows to organise an IndoorGML model as a collection of layers with different themes. Those concepts are elaborated in the following subsections.
7.1. Space
The notion of space is widely explored in spatial science and urban applications in general (Zlatanova, et al., 2020). Among its diverse definitions that can be found in dictionaries and related literature, one definition of the space encapsulates most of the concepts attached it:
“Space is either unlimited expand or an empty area usually bounded in some way between things (e.g., the architect left space in front of the building) or an area reserved for some particular purpose (e.g., the laboratory’s floor space)” (Princeton University, 2010).
That definition acknowledges three main aspects of the space:
its ability to expand infinitely,
its intuition to be generally empty and eventually bounded (particularly in the built environment) and
its functional property.
In IndoorGML, the space is characterized by all those properties, except IndoorGML space is not necessarily empty. Depending on the IndoorGML extension (indoor navigation, sensors coverage, ownership, etc.) spaces can be empty, non-empty or partially empty.
The indoor space is commonly perceived as a space within a building. It incorporates architectural components such as walls, slabs, doors, etc., furniture such as chairs, tables, desks and the remaining empty spaces as in rooms, corridors, halls, etc. IndoorGML 2.0 focuses on the empty spaces where objects can be located, and activities can be hosted for indoor navigation or LBS. Consequently, the relationships between spaces are of critical importance.
Spaces in the built environment are not always sharply distinguishable. Many spaces cannot be strictly categorised as indoor or outdoor, but rather as semi-spaces often linking indoor and outdoor environments (Yan, Diakité, Zlatanova, 2019; Zlatanova, et al., 2020). For example, an inner court, a veranda, a balcony, or an open bridge can belong to a building, without being entirely enclosed within the shell of the building. Nevertheless, for a matter of completeness, IndoorGML can account for all types of space within the built environment, as long as they can be represented with the IndoorGML Cellular space concept.
7.2. Cellular space
A cellular space is a set of cells (or CellSpaces) defined as the smallest organizational or structural unit (Princeton University, 2010) and grouped according to thematic criteria (e.g. topographic space, sensor coverage space, etc.). A cellular space S of thematic layer T, noted ST is defined as follows:
ST= {c1, c2, …, cn}
where ci is ith cell. Every cell in a cellular space can have the following properties:
a unique identifier ;
a name (e.g. a room number);
a geometry (e.g. solids in 3D or surfaces in 2D)
Figure 4 illustrates a cellular space consisting of cells, which represent rooms, corridors, doors and windows in a building.
Figure 4 — a) A building and b) the corresponding cellular space, containing all empty cells and c) corresponding cells of a room, a corridor and their openings.
Within a cellular space, only the adjacency relationship is allowed between cells, that is, no overlap may occur. Overlapping cells must be organised in a new cellular space. A cellular space may be incomplete coverage, i.e. it is possible to have gaps between cells (Figure 5).
Figure 5 — Cellular space containg disconnected cells, i.e., all offices in an university building (Allatas et al. 2017)
In IndoorGML, a cellular space can be subdivided into smaller cells or aggregated into larger ones. Those operations detailed in Clause 7.2.3 allow for both a tailored geometric granularity and functional specification of spaces.
7.2.1. Geometry
Every cell defining an item in indoor space owns a shape, size and location that can be collected and modeled. It can represent physical features such a room, door, wall, or virtual spaces such as legal rights and access or sensors coverages. Depending on the application, the geometry of a cell can be simplified and generalised into a minmax bounding box. Such approach can be applied when considering highly irregular shapes like furniture. Geometric information can be included in IndoorGML either directly or via an external link. Geometry of cells can be omitted as well.
Geometry of cells is defined in Euclidean space and provides the means for the quantitative description of the spatial characteristics of cell. Metrics is defined as in (Morris, 2023). IndoorGML cells are modeled as features and follow ISO 19107 (Spatial Schema)(ISO, 2019) provides conceptual schemas to describe and model real world objects as features.
Figure 6 — Three options to represent geometry in IndoorGML
As illustrated in Figure 6, there are three options for representing geometry of a cell in indoor space:
Geometry in IndoorGML (Option 1): geometric representation of cell may be included within an IndoorGML document. It is GM_Solid in 3D space and GM_Surface in 2D space as defined in ISO 19107. Note that solid with holes or surface with holes are allowed in this standard.
External Reference (Option 2): instead of explicit representation of geometry, an IndoorGML document can only contain external links to objects defined in other data sets such as IFC or CityGML, where the referenced objects in external data set include geometric information. Then there must be 1:1 or n:1 mapping from cells in IndoorGML to corresponding objects in other datasets.
No Geometry (Option 3): no geometric information is included in IndoorGML. This means that the shape, extend and location are unknown. The cell is defined by its identifier.
Note that Option 2 can always be used in combination with the other options. When Option 1 is used, three fundamental operations can be applied to cell spaces: subdivision, aggregation, and selection.
7.2.2. Topology
Beside the geometry of a cellular space, it is also possible to represent cells in the Topological space by a topological model, representing the relationships between points, lines and polygons constructing the geometry (Gröger and George, 2012). Such topological models are dedicated to representing spatial relationships thus their shape and size is not described (Egenhofer et al. 1989). This is to say, geometric predicates such as volumes, areas, distances cannot be computed. As mentioned above IndoorGML deals only with cells in 3D and 2D, which are presented as solids or polygons. Consequently, the topological model contains only 3D and 2D objects in 3D cellular space and 2D and 1D objects in 2D cellular space. More information about topology of cells can be found in Clause 8.1.3
7.2.3. Subdivision, aggregation, and selection
The indoor environment is complex and indoor spaces often have hierarchical structures. For several indoor applications, a careful decomposition of an indoor space is required to reflect these hierarchical structures. To support the representation of such configurations, the subdivision, aggregation, and selection processes on the CellSpaces can help achieve them.
Figure 7 — a) A furnished indoor space. b) Subdivision of the indoor space into two separate rooms with exclusion of furnishing elements' spaces. c) Selection of specific CellSpaces (green) suitable for walking and rolling. d) CellSpaces (green) suitable for flying.
As illustrated in Figure 7, the subdivision consists in splitting the original cells into several subspaces of different geometry, according to their function. For example, in Figure 7.b, the indoor space is subdivided into several. This subdivision allows to segment Figure 7.a in subspaces of different functions, e.g., a kitchen and a living room, as well as discriminating the spaces physically occupied by items. The subdivision process could be based on any application-based criteria and all resulting subspaces are CellSpaces of a cellular space. For the purpose of navigation applications, subdivisions may be required because of:
geometry simplification, e.g., working with spaces that have only convex shapes
increase of granularity, e.g., in for improving the localisation of people and items.
need to identify specific functional/perception spaces, e.g., waiting or smoking areas.
defining free spaces, e.g., spaces free of obstacles.
The aggregation process is the reverse of the subdivision, which leads subspaces to be merged instead of being split. Therefore, the merging of all subspaces ofFigure 7.a allows to retrieve the original cell spaces of Figure 7.a. Similarly, any new cell resulting from this process is a CellSpace of a cellular space. For the purpose of indoor navigation, aggregation may be required when:
There are CellSpaces of no interest for an application, e.g., induvial toilets or service areas in a building
There are CellSpaces, which are not accessible for specific users, e.g., restricted areas at hospitals and airports.
Finally, the selection allows to discriminate the CellSpaces of interest from the rest. Figure 7.c and d show a scenario where only CellSpaces that can support a certain type of locomotion mode are considered in the cellular space (see the green CellSpaces). The selection of spaces for indoor navigation applications can take place for many different reasons:
to reduce the overall number of spaces, e.g., select only empty spaces, such as rooms and corridors and avoid non-empty spaces such as walls, slabs, or too crowded areas.
to eliminate spaces, which will not be used for a specific user: e.g., select only common spaces for a visitor of a public building
to eliminate spaces of danger: e.g., in emergency cases, select only spaces which are still safe for users to be in.
7.3. Poincaré Duality
Topological relations between cells is crucial in IndoorGML. They allow establishing links between cell in the same or different thematic layers, which is critical information for several applications such as navigation and LBS. As mentioned above, a topological model of cellular space is partial and represents only relations between cells and their boundaries. The Poincaré duality (Munkres, 1984) is further employed to explicitly describe the relationships between the cells. It provides a theoretical background for mapping cellular space to a graph or network to represent allowed topological relationships. It simplifies the complex spatial relationships, which may occur especially in 3D by a topological model (Lee, 2004).
The Poincaré duality refers to two spaces namely Primal Space and Dual Space. A k-dimensional object in N-dimensional Primal Space is mapped to (N-k) dimensional object in Dual Space. Thus, solid 3D objects in 3D Primal space, e.g., rooms within a building, are mapped to nodes (0D object) in dual space. 2D surface shared by two 3D objects is transformed into an edge (1D) linking the two nodes in Dual space. The nodes and edges in Dual space form an adjacency graph. The nodes and the edges of Dual space represent abstractions of cells and their adjacency relationships in Primal space.
Figure 8 — Principles of Poincaré duality. a) 3D Primal space case and b) 2D case. (Mathematical definition of Poincaré duality in (Munkres, 1984))
Figure 8 illustrates this duality transformation for the case where the primal space is 3D and 2D respectively. Note that the transformations from 1D object (curve) or 0D object (point) in 3D Primal space are not included in IndoorGML since they are not considered as cells in most applications. But the transformation may be applied to 1D or 0D objects of 3D primal space in a similar way if it is required. Then the adjacency graph Gadj is defined as follows:
Gadj = (V, Eadj)
where V and Eadj are sets of nodes and edges in dual space mapped from cells and surfaces in 3D primal space, respectively. The connectivity graph Gcon is a subset of the adjacency graph and represent only adjacency that make the spaces connected. For navigation cases connectivity between spaces (i.e., room) is provided via the notion of doors between the rooms. It is defined as:
Gcon = (V, Econ)
where V and Econ are sets of nodes and edges in dual space mapped from cells and surfaces in 3D primal space, respectively. Figure 9 illustrates cellular space and its connectivity graph.
Figure 9 — a) Poincaré duality on 3D cells of a building; b) Corresponding adjacency graph in the dual space; c) Combined primal and dual space view.
The adjacency graph can be represented as a logical network or geometric network. While the logical network represents only the relationships between the cells, the geometric network holds geometry for nodes and edges.
7.4. Structured space model
The Primal and Dual spaces and the Euclidean and Topological spaces are interlinked in a Structured Space Model as illustrated in Figure 10. The Primal space refers to either Euclidean or Topological space and the Dual space refers to either Geometric network or Logical network. Geometry of Cellular Space and Geometric Network are embedded in the Euclidean space, while Topology of Cellular Space and Logical Network are defined in the Topological space. IndoorGML supports the Primal and Dual models in the Euclidean space and the Logical Network in the Topological space. As mentioned above, the Geometry for Cellular space is not compulsory, as the cellular space can be identified. IndoorGML is valid with at least one of the Primal spaces. See examples in <Clause 9.
The Euclidean space (Geometry) is estimated to be the most useful for applications such as navigation and LBS. IndoorGML may then containing both Geometry and Geometry Network, or only Geometry, or only Geometric Network. Other types of applications, such as dealing with ownership or sensor coverage, may be better supporter by IndoorGML containing Geometry and Logical Network or Topology and Logical Network.
Figure 10 — Structured space model: mapping between Euclidean and Topological spaces, and Primal and Dual Spaces
7.5. Semantics
IndoorGML offers a basic semantic for the Primal and Dual spaces of the core module. The semantics of the core model is generic for all applications as it does not specify any other information about the Primal and Dual Spaces, except some characteristics such as name, level, and PoI. If no extension module is involved, the cells carry the semantics of the core module only.
Further semantic specifications are provided via the Extension modules as specified in Clause 8.2. Every cell is further classified according to the semantic introduced by the extension module. IndoorGML 2.0 maintains semantics for Indoor navigation which is provided within Navigation extension module. The semantics, developed through the Navigation extension module is intended for two purposes to: 1) provide a classification of a cell, and 2) determine adjacency relationships that ensure connectivity between cells. Semantics thus allows to define cells that are important for navigation. Thus, a cell can be classified as navigable (room, corridor, hall), non-navigable (wall, slab, furniture), opening (door, window), etc. (see Clause 8.2). The subdivision and classification of Cellular space relies on the architectural layout of a building.
While this may be enough for some cases based on connectivity graph analysis, it can rapidly be limiting for more specialized applications such as sensor managements, legal aspects or security, where advanced, specific semantic needs to be associated to the geometric and topological elements. Examples can be a Legal Extension module, in which a cell might be classified as ‘ownership’, ‘restriction’, ‘responsibility’ etc. or a Security extension module that may offer semantics that would indicate ‘check-in’, ‘boarding’, ‘crew entrance’, etc.
Semantic extension mechanism allows to add more semantic on primal or dual spaces, as long as they follow the modularization principle. Cells can be organised in a hierarchical structure according to their semantics, corresponding properties, and semantic interrelations (specialisation and generalisation). For example, ‘room’ is a specialization of ‘navigable cell’ and ‘non-navigable cell’ is a generalization of ‘walls’ and ‘obstacles’. Cells created for one space representation may be aggregated or subdivided for the purpose of another one. More details about the Navigation extension module are given in Clause 8.2.
7.6. Thematic layers
A single indoor environment can be organised in many kinds of cellular spaces with distinct subdivision and semantic specifications. Within each Extension module, it is possible to have many different subdivisions and each cellular space is targeted towards specific applications and needs. A cellular space with a specific semantics and/or geometric subdivision, aiming to reflect a group of application can be organised in a Thematic Layer. Thematic layers can be defined using the Extension modules and/or Core module. Thematic layers making use of the semantics of Core module only, can be derived applying the principles of space partitioning, i.e., subdivision, aggregation and selection. Examples of such thematic layers are subdivision according to Wi-Fi or RFID coverage (see example below). The Navigation extension module provides additional notions for navigability and connectivity. Therefore, thematic layers that rely of these properties, should include Navigation extension module. Navigation-based themes can be defined using a particular space partitioning with respect to:
tasks: visitor, staff, facility manager, emergency responder (see Figure 11)
user characteristics: age, gender
mode: walking, driving, flying (see Figure 7.c and Figure 7.d)
IndoorGML 2.0 is organised as a collection of interconnected layers representing different themes of the same physical space. Figure 11 represents a thematic layer ‘Visitors’, which contains all cells, which are accessible to visitors in a university faculty (Alattas et al 2017). Similarly, cellular spaces can be created for students or facility management. All spaces use the semantics of the Navigation extension module, but a selection of spaces is made according to the user tasks. Similarly, cellular spaces from different extension modules can be organised in thematic layers.
Figure 11 — Cellular space for visitors (Alattas et al 2017)
In Figure 12, a physical indoor space is organized according to the Navigation extension module Navigation, named Topographic layer. In addition, two cellular subdivisions called Wi-Fi and RFID are specified, which rely on the semantics of the core model only. The Topographic layer, created under the Navigation extension module, follows the architectural layout of a building, and is composed of rooms, corridors, and stairs. Wi-Fi and RFID cells follow the outlines of the corresponding sensor coverages. The three cellular spaces, although related to distinct semantics and subdivision approaches, form each a thematic layer. These three thematic layers may be appropriate for an application that provides tracking and navigation.
Following the modularization mechanisms, every layer in IndoorGML contains the core module, which is composed of Primal space and Dual space. A valid thematic layer should contain at least one of the four space representations, i.e., Geometry, Topology, Geometric network or Logical network.
Figure 12 — Three different cellular spaces for the same physical space
7.6.1. Multiple-Layered Space representation
IndoorGML provides mechanisms for maintaining and linking multiple Thematic layers for a same indoor environment. Figure 13 represents the three thematic layers discussed above.
Figure 13 — Corresponding Primal and Dual spaces of different thematic layers
This representation method with multiple cellular space layers is called Multiple Layered Space Representation (MLS Representation). The MLS representation is useful for many purposes. For example, we can represent the hierarchical structure of indoor space by MLS representation, where each level is represented as a single space layer. Another application example of MLS representation is indoor tracking with presence sensors such as RFID, as shown in Figure 12. Given an indoor space represented as topographic cellular space layer and RFID sensor coverage layer respectively, we can deduce the movement of a mobile object with a RFID tag by the sequence of RFID coverage cells and corresponding inter-layer space edges.
7.6.2. Inter-Layer Relations
To handle the interaction between several layers, it is necessary to represent the relationships between them. IndoorGML does this through the Inter-Layer connection which describes the spatial relationships (topology) between two layers. Unlike the topological relationships between cells of a same layer which are ruled by the Poincaré Duality (adjacency only), the inter-layer relations are ruled by the 9-intersection model (Egenhofer 1989). IndoorGML 2.0 concentrates on six relationships namely contains, within, covers, coveredBy, overlaps and equals between cells in the Primal space and nodes in Dual space and their combinations
As illustrated in Figure 13, there are three space layers, where each layer has its own primal and dual space representation. Following the same indoor tracking example, Figure 14 illustrates the inter-layer relations between the dual spaces of the layers in Figure 12. In a topographic layer, the nodes represent the possible states of a navigating object and correspond to cells with volumetric extent in primal space (e.g., rooms) while the edges represent state transitions, i.e., the movement of an object from one space to another. They correspond to connectivity relations between the cells in primal space (e.g., neighboured rooms connected with a door). In the sensor space, the graph has a slightly different structure. The nodes represent again the cells with volumetric extend (e.g., the entire coverage space of a Wi-Fi transmitter), while the edges represent the transition from one space to another based on the neighboring Wi-Fi coverage spaces. Since the layers cover the same real-world space, the separated dual graphs can be combined into a multi-layered graph.
Figure 14 — Inter-Layer relations between three different layers of a same environment
Figure 14 represents relationships in the Dual space between the three Primal spaces given in Figure 13: topographic and two sensors’ spaces Wi-Fi and RFID. A novelty in IndoorGML 2.0 is the possibility to represent an inter-layer connection between two primal spaces. This is illustrated in Figure 15 where the inter-layer mechanism is used to represent a furnished room with a combination of two layers: a first one describing solely the cells of the room and opening (Figure 15.b) and a second one describing the CellSpaces of the furniture (Figure 15.c). The relationship between the two layers can be qualified as a containment (layer 1 contains layer 2, or layer 2 is within layer 1). This allows describing complex scenes while respecting the non-overlapping constraint of Poincare duality.
Figure 15 — Inter-layer connection between two primal spaces: a) furnished room; b) cells of the room and door only; c) cells of furnishing elements only represented by minmax boxes.
8. Data Model
After explaining the important concepts on which IndoorGML relies, this section presents the conceptual data model using UML class diagram.
8.1. IndoorGML Core Module
The core module is composed of three main parts:
the primal space which describes the cellular space (see Clause 7.2);
the dual space which carries the network information (see Clause 7.3);
the inter-layer connection which makes the link between thematic layers (see Clause 7.6.2).
In Figure 16, the UML diagram illustrates all the classes associated with those three parts. In the following, the classes are introduced and the data types that they invoke in their attributes are detailed.
Figure 16 — UML diagram of the Core module
8.1.1. CellSpace
Figure 17 — CellSpace and its related classes: PrimalSpaceLayer, CellBoundary, Node and InterLayerConnection
CellSpace is a core module class for representing the environment in terms of cellular space. CellSpace is a compulsory class to have a valid IndoorGML 2.0. It contains the following attributes (Figure 17):
cellSpaceGeom (CellSpaceGeometryType)
externalReference (url)
level (CharacterString)
name (CharacterString)
PoI (Boolean)
The cellSpaceGeom attribute carries an instance of type CellSpaceGeometryType allowing the description of geometric representations of space. A CellSpaceGeometryType is a geometry class type with two possible attributes: Geometry3D or Geometry2D. They provide 3D and 2D description of a CellSpace instance. The Geometry3D attribute describes a representation of type solid, similar to the GM_Solid (ISO 19107) type. It is the default type for describing a 3D CellSpace as one single valid entity. The Geometry2D attributes describe a representation of type surface, similar to the GM_Surface type. It is meant for describing a CellSpace in 2D as one single surface (in the case of a 2D IndooGML model). The geometry should be valid according to the ISO 19107 standard terms. If a CellSpace cannot meet those requirements, e.g., be valid 2D or 3D geometry, the option to describe its geometry as a set of CellBoundary entities can be considered. The CellSpace can be defined without geometry as well.
The attribute externalReference is used for the reference of an object to its corresponding object in an external data set. A CellSpace also carries a level information, which can be left empty when it cannot be clearly identified. This is the case for example for a CellSpace that aggregates several cells spanning across multiple stories. The value of level is given as a string rather than an integer because it is sometime given as plain text “M” for mezzanine floor and “RC” for ground floor. A newly introduced attribute is name. This is destined to record the name given to a space according to any internal convention (e.g. MR.403 for meeting room 3 at level 4, or coverage of Wi-Fi 234). This is a common practice for large buildings and this attribute helps simplifying space queries for applications. Another new attribute PoI is introduced to allow CellSpace elements to be flagged as Point of Interest for LBS applications. The attribute is a simple Boolean allowing the implementation of special considerations for flagged cells.
Note that apart from the PoI attribute, all applicable attributes of a CellSpace can be null. For example, a network only IndoorGML model would not need a cellular space with explicit geometric description. However, CellSpace instances should always be described in an IndoorGML model (even without geometry attribute) as they may carry all the important information related to the primal space that other features from the dual space or other layers may need (e.g. a node can be identified as a PoI or associated with a name thanks to the attribute of its primal space).
In terms of relationships, a CellSpace instance can describe relationship with multiple CellBoundary entities, which represent its surrounding boundaries partially or fully through the boundedBy attribute. For example, choice can be made to store only boundaries which are important for the Dual Graph (e.g., boundaries that reflect adjacency between CellSpaces). In the case where a CellSpace does not carry the geometry of type Solid and uses a boundary-based representation instead, then all boundaries might be needed (to derive the geometry of the nodes or for visualisation). Finally, with the duality attribute, a CellSpace can describe a reference to one Node instance corresponding to its representation in the dual space.
CellSpace instances are aggregated in a PrimalSpaceLayer according to a specific theme as explained in Clause 7.6. In case of multiple PrimalSpaceLayers, the class InterLayerConnection establishes the link between the depended CellSpace instances.
8.1.2. CellBoundary
Figure 18 — CellBoundary and its related classed: PrimalSpaceLayer, CellSpace and Edge
CellBoundary is a core module class to describe the boundary of each cell in a cellular space (Figure 18). Unlike CellSpace, CellBoundary is not a compulsory class. It is only required when Edge instances exist in the model. It contains the following attributes:
cellBoundaryGeom (CellBoundaryGeometryType)
externalReference (url)
isVirtual (Boolean)
The cellBoundaryGeom geometry attribute of the CellBoundary carries the geometry (of type CellBoundaryGeometryType) which is generally described by a surface in 3D or a curve in 2D. A CellBoundaryGeometryType is a geometry class type similar to the CellSpaceGeometryType, with two possible attributes: Geometry2D and Geometry1D. The Geometry2D attribute is the same than that of CellSpaceGeometryType. Note, in this context, it is embedded in 3D, i.e., it has 3D coordinates and represents a part of the boundary of a CellSpace. The Geometry1D attribute describes a representation of type curve, GM_Curve type. Note, it is meant it is intended for describing a CellBoundary in 2D as one single line/curve and has 2D coordinates. This makes it adequate for representations based on 2D floor plans. CellBoundaryGeom can be omitted. In this case, CellBoundaryGeom indicates only if a specific cell boundary is virtual.
The attribute externalReference is used for the reference of a geometric object to its corresponding object in an external data set and can be given by the url of the file containing the geometry. The is_Virtual attribute is a Boolean value used to indicate whether a CellBoundary corresponds to a virtual surface (true) or a physical one (false), which should be the default value. Virtual boundaries are common in 3D indoor models, mainly when a space subdivision is applied.
Additionally, a CellBoundary can be linked to one Edge instance via the duality attribute, which corresponds to its dual representation. Unlike CellSpace, it is not a mandatory class in an IndoorGML model. In the case where there are CellSpace entities but no CellBoundary, the network should be derived from the cells using geometric operations.
In the case where there are CellBoundary entities provided without geometric attributes in the model, only logical networks can be safely derived between two CellSpace entities sharing any of those CellBoundary. Therefore, providing geometric networks will still involve similar issues described previously. A final scenario may see an IndoorGML model with geometry information only with CellBoundary instances but not for CellSpace. That case is likely to happen if a solid geometry cannot be provided for a CellSpace, and a set of surface boundaries are provided with no guarantee of closure. In that case the generation of a Node for a CellSpace should be completed from CellBoundary instances, while guaranteeing its position inside the described space.
8.1.3. PrimalSpaceLayer
Figure 19 — PrimalSpaceLayer and its related classes: CellSpace, CellBoundary and Thematic Layer
PrimalSpaceLayer is a core module class representing the primal cellular spaces of a given thematic layer (Figure 19). It aggregates CellSpace and CellBoundary (which are directly associated with their corresponding geometry attributes) to represent spatial objects in primal space. The PrimalSpaceLayer class has the following attributes:
function (CodeList)
creationDate (DateTime)
terminationDate (DateTime)
With the attribute function, nominal and real functions of a space layer are depending on the Thematic layer and can be described as proposed in a CodeList. The creationDate and terminationDate attributes can be used to describe the chronology of the layer. The points of time refer to real world times.
A PrimalSpaceLayer instance also provides references to its CellSpace and CellBoundary entities through the cellSpaceMember and cellBoundaryMember elements.
8.1.4. Node
Figure 20 — Node and its related classes: CellSpace, Edge, DualSpaceLayer and InterLayerConnection
Node is a core module class to represent a node in dual space (Figure 20). It has one attribute:
geometry (GM_Point)
The value of geometry corresponds to a 2D or 3D Point in IndoorGML, but its cardinality can be 0 (no geometry provided) or 1. Because a Node is always the dual space abstraction of a primal space cell, it has always an association with its corresponding CellSpace (e.g., room, door, sensor coverage, etc.) through the duality attribute. This way, a Node can always access to the information related to the cell it is representing (e.g., geometry, semantic, etc.). Note that the associated CellSpace may not carry any information as well, except the functional information for the specific cellular space. Additionally, a Node is also associated with at least one Edge instance that is linked to it via the connects attribute.
8.1.5. Edge
Figure 21 — Edge and its related classes: CellBoundary, Node and DualSpaceLayer
Edge is a core module class that represents the adjacency or connectivity relationships among Node elements representing space cells in primal space (Figure 21). It carries the following attributes:
geometry (GM_Curve)
weight (real)
The attribute geometry provides the description of a 2D or 3D curve, but similarly to Node entities its cardinality can be 0 or 1 as well. The attribute weight can be used for graph-based applications (e.g., in order to deal with the impedance representing absolute barriers in transportation problems).
An Edge may be associated with a CellBoundary instance of the primary space via its duality attribute. This association can be skipped in situations where a CellBoundary is not necessary to represent the link between two CellSpace entities (e.g., for logical networks or visibility graphs where two CellSpaces connected by visibility may not share a CellBoundary). Finally, an Edge always connects two Nodes.
8.1.6. DualSpaceLayer
Figure 22 — DualSpaceLayer and its related classes: Node, Edge and Thematic Layer
DualSpaceLayer is a feature class for representing the dual space features (e.g., room network) of a given thematic layer. It is composed of Nodes and Edges to represent the topology of objects from the primal space. It has the following attributes:
isLogical (Boolean)
isDirected (Boolean)
creationDate (DateTime)
terminationDate (DateTime)
While creationDate and terminationDate are similar to those of PrimalSpaceLayer, the isLogical attribute allows to differentiate whether the provided network is a geometric or a logical network. This difference may matter for certain applications such as navigation, where a logical network would not be sufficient to evaluate travel distances between cells. Similarly, the isDirected attribute allows to specify if the graph associated with the DualSpaceLayer is directed or not. A directed graph implies that the node directions should be considered in the applications. Currently, the order of the nodes in the implementation formats determines their direction. Additionally, a DualSpace provides references to all its related Node and Edge entities through its nodeMember and edgeMember attributes.
8.1.7. InterLayerConnection
Figure 23 — InterLayerConnection and its related classes: CellSpace, Node, ThematicLayer and IndoorFeatures
The InterLayerConnection class describes the connection between two layers in IndoorGML, either of type PrimalSpaceLayer or DualSpaceLayer (Figure 23). It contains the following attributes:
typeOfTopoExpression (TopoExpressionValue)
comment (CharacterString)
The typeOfTopoExpression attribute represents the topological relationship between two layers. It comes as a code list with the following values: contains, within, covers, coveredBy, overlaps, and equals. Those topological values are in the form of verbs for which the subject is the first instance of the connectedLayers attribute. In other words, for two layers successively described by the connectedLayers attribute, e.g., Layer 1 and Layer 2, one should read Layer 1 typeOfTopoExpression Layer 2 (e.g., Layer Room contains Layer Furniture).
An InterLayerConnection also describes the cells or nodes that are connected between two layers, using the connectedCells and/or connectedNodes attributes. The former is used when the connection is between two primal spaces and the latter is used otherwise. Finally, the comment attribute can contain an additional description for the InterLayerConnection.
8.1.8. ThematicLayer
Figure 24 — ThematicLayer and its related classes: PrimalSpaceLayer, DualSpaceLayer, InterLayerConnection and IndoorFeatures
The ThematicLayer is a core module class introduced in IndoorGML 2.0, as an aggregation of PrimalSpaceLayer and DualSpaceLayer instances to allow definition of Thematic layers separately (Figure 24). Note, IndoorGML 1.1 enables the multi-layer mechanism only for the dual space (the networks).
The class comes with the following attributes:
semanticExtension (Boolean)
theme (ThemeLayerValue)
The semanticExtension attribute is set as a boolean as it is simply an indication that there is Extension module with additional semantic information associated to the PrimalSpaceLayer. IndoorGML 2.0 maintains only the Navigation extension module (see Clause 8.2), a boolean is considered enough to indicate its presence. This is however susceptible to evolve in the future (e.g., into a codeList). The theme attribute determines what type of representation of the model can be expected in the corresponding layer (e.g., topographic). It comes in the form of a code list which tells whether the layer is of type Physical, Virtual, Tags or Unknown.
A Physical layer is a layer that describes the indoor space on the basis of its physical constraints (e.g. the topographic cellular space in Figure 12). It is the most common type of layers for applications like indoor navigation, where the physical elements are highly constraining the use of the space. Similarly, a layer is qualified as Virtual when its description of the space relies on exclusively virtual, or a combination of physical and virtual extents. It is the case for example for functional spaces that can represent spaces necessary for some indoor objects to operate or to be used properly (Diakité, 2018). It is also the case for sensor spaces such as the Wi-Fi spaces represented in Figure 12. Finally, the Tags type is useful for describing layers that use symbols or tags to represent the cellular space. It is a useful representation when the real geometry of the CellSpaces of a given layer are not relevant for a given application. PoI are often represented in a separate layer with their locations only (e.g., in Dual Space). Finally, any layer the does not fall in those previous categories will take the Unknown type.
9. Data Dictionary and Requirements
In this section, we present the data dictionary of the feature types defined in IndoorGML 2.0 UML class diagram. It aims to clarify the concepts of each feature type and help the implementation of this standard. The data dictionary is defined based on ISO standards from TC 211, particularly ISO 19109 for the rules for application schema, ISO 19107 for spatial schema, and ISO 19136-1 for GML. As IndoorGML 2.0 is an application schema from these base standards, we will not include the data dictionary for the feature types defined by these standards in section. For example, the properties of GML AbstractFeature such as gmlID, and name are not described in the data dictionary. The data dictionary of the feature types defined in Clause 8 is given in the following subsections.
9.1. Feature Types in Core Module
Requirements class 1 | |
|---|---|
| Identifier | http://www.opengis.net/spec/indoorgml/2.0/req/core |
| Target type | Implementation Specification |
| Conformance class | Conformance class A.2: http://www.opengis.net/spec/indoorgml/2.0/conf/core |
| Normative statements | Requirement 1: /req/core/thematiclayer Requirement 2: /req/core/cellspace Requirement 3: /req/core/cellboundary Requirement 4: /req/core/node Requirement 5: /req/core/edge Requirement 6: /req/core/interlayerconnection |
9.1.1. IndoorFeatures
Table 2 — Data dictionary of IndoorFeatures
| Name | IndoorFeatures | |
|---|---|---|
| Definition | Set of all features and their relationships to describe a given indoor space. | |
| Super classes | GML AbstractFeature | |
| Composition | Role name | Type and Cardinality |
| layers | ThematicLayer [1..*] | |
| layerConnections | InterLayerConnection [0..*] | |
| Properties | Property name | Type and Cardinality |
| none | ||
| Constraints | Constraint ID | Constraint |
| none | ||
9.1.2. ThematicLayer
Table 3 — Data dictionary of ThematicLayer
| Name | ThematicLayer | |
|---|---|---|
| Definition | Aggregation of features for a specific theme consisting of primal space layer and dual space layer. | |
| Super classes | GML AbstractFeature | |
| Association | Role name | Type and Cardinality |
| connectedLayers | InterLayerConnection [1..1] | |
| Properties | Property name | Type and Cardinality |
| semanticExtension | Boolean [1..1] | |
| theme | ThematicLayerValue[1..1] | |
| Constraints | /req/core/thematiclayer | |
Requirement 1 | |
|---|---|
| Identifier | /req/core/thematiclayer |
| Included in | Requirements class 1: http://www.opengis.net/spec/indoorgml/2.0/req/core |
| A | Any feature of a thematic layer shall belong to the same theme. |
9.1.3. PrimalSpaceLayer
Table 4 — Data dictionary of PrimalSpaceLayer
| Name | PrimalSpaceLayer | |
|---|---|---|
| Definition | Aggregation of cell spaces and cell boundaries describing the topography of a given theme in indoor space. | |
| Super classes | GML AbstractFeature | |
| Aggregation | Members | Class and Cardinality |
| cellSpaceMember | CellSpace [1..*] | |
| cellBoundaryMember | CellBoundary [0..*] | |
| Properties | Property name | Type and Cardinality |
| function | GenericName [0..1] | |
| creationDate | DateTime [0..1] | |
| terminationDate | DateTime [0..1] | |
| Constraints | none | |
9.1.4. CellSpace
Table 5 — Data dictionary of CellSpace
| Name | CellSpace | |
|---|---|---|
| Definition | the basic unit of indoor space, such as room and corridor, the union of which makes the entire indoor space. | |
| Super classes | GML AbstractFeature | |
| Association | Role name | Type and Cardinality |
| boundedBy | CellBoundary [0..*] | |
| duality | Node [0..1] | |
| Properties | Property name | Type and Cardinality |
| cellSpaceGeometry | CellSpaceGeometryType[0..1] | |
| externalReference | ExternalReferenceType [0..1] | |
| level | CharacterString [0..1] | |
| name | CharacterString [0..1] | |
| PoI | Boolean [1..1] | |
| Constraints | /req/core/cellspace | |
Requirement 2 | |
|---|---|
| Identifier | /req/core/cellspace |
| Included in | Requirements class 1: http://www.opengis.net/spec/indoorgml/2.0/req/core |
| A | Cell spaces belonging to the same primal space layer shall not overlap. |
9.1.5. CellBoundary
Table 6 — Data dictionary of CellBoundary
| Name | CellBoundary | |
|---|---|---|
| Definition | explicit boundary of cell space, to which we may assign additional properties such as material, texture, etc. | |
| Super classes | GML AbstractFeature | |
| Association | Role name | Type and Cardinality |
| bounds | CellSpace [1..2] | |
| duality | Edge [0..1] | |
| Properties | Property name | Type and Cardinality |
| cellBoundaryGeometry | CellBoundaryGeometryType [0..1] | |
| externalReference | ExternalReferenceType [0..1] | |
| isVirtual | Boolean | |
| Constraints | /req/core/cellboundary | |
Requirement 3 | |
|---|---|
| Identifier | /req/core/cellboundary |
| Included in | Requirements class 1: http://www.opengis.net/spec/indoorgml/2.0/req/core |
| A | Cell boundaries belonging to the same primal space layer shall not intersect. |
| B | The geometry of cell boundary shall not exceed the extent of the corresponding cell space. |
9.1.6. DualSpaceLayer
Table 7 — Data dictionary of DualSpaceLayer
| Name | Node | |
|---|---|---|
| Definition | Dual space layer corresponds to primal space layer and mainly describes adjacency or connectivity relationship between nodes, where node is an abstraction of cell space and edge is a relationship between two nodes. It is a graph composed of nodes and edges. | |
| Super classes | GML AbstractFeature | |
| Aggregation | Role name | Aggregated Class and Cardinality |
| nodeMember | Node [1..*] | |
| edgeMember | Edge [0..*] | |
| Property | Property name | Type and Cardinality |
| isLogical | GM_Curve [0..1] | |
| creationDate | DateTime [10..1] | |
| terminationDate | DateTime [10..1] | |
| isDirected | Boolean [1..1] | |
| Constraints | none | |
9.1.7. Node
Table 8 — Data dictionary of Node
| Name | Node | |
|---|---|---|
| Definition | space abstraction of cell space in dual space to a point or virtual point, which is defined as 0-dimentional topological primitive in ISO 19107. | |
| Super classes | GML AbstractFeature | |
| Association | Role name | Type and Cardinality |
| connectedNodes | InterLayerConnection [0..*] | |
| duality | CellSpace [0..1] | |
| connects | Edge [0..*] | |
| Properties | Property name | Type and Cardinality |
| geometry | GM_Point [0..1] | |
| Constraints | /req/core/node | |
Requirement 4 | |
|---|---|
| Identifier | /req/core/node |
| Included in | Requirements class 1: http://www.opengis.net/spec/indoorgml/2.0/req/core |
| A | When the isLogical attribute of a DualSpaceLayer is set to TRUE, the geometries of its Node instances shall be spatially located inside of their corresponding Cell Spaces. |
9.1.8. Edge
Table 9 — Data dictionary of Edge
| Name | Edge | |
|---|---|---|
| Definition | adjacency or connectivity relationship between nodes, which is defined as 1-dimensional topological primitive in ISO 19107. | |
| Super classes | GMLAbstractFeature | |
| Association | Role name | Type and Cardinality |
| connects | Node [2..2] | |
| duality | CellBoundary [0..1] | |
| Properties | Property name | Type and Cardinality |
| geometry | GM_Curve [0..1] | |
| weight | Real [1..1] | |
| Constraints | /req/core/edge | |
Requirement 5 | |
|---|---|
| Identifier | /req/core/edge |
| Included in | Requirements class 1: http://www.opengis.net/spec/indoorgml/2.0/req/core |
| A | Self-intersection shall not be allowed when its geometry is given. |
| B | If dualspaceLayer.directed=true, then the order of nodes shall be representing the direction. |
9.1.9. InterLayerConnection
Table 10 — Data dictionary of InterLayerConnection
| Name | InterLayerConnection | |
|---|---|---|
| Definition | Relationship between cell spaces and nodes in two different thematic layers | |
| Super classes | None | |
| Association | Role name | Type and Cardinality |
| connectedLayers | ThematicLayer [2..2] | |
| connectedNodes | Node [0..2] | |
| connectedCells | CellSpace [0..2] | |
| Properties | Property name | Type and Cardinality |
| comment | CharacterString [1..1] | |
| typeOfTopoExpression | TopoExpressiveValue [1..1] | |
| Constraints | /req/core/interlayerconnection | |
Requirement 6 | |
|---|---|
| Identifier | /req/core/interlayerconnection |
| Included in | Requirements class 1: http://www.opengis.net/spec/indoorgml/2.0/req/core |
| A | Two target cell spaces (or nodes) shall not belong to a same primal space layer (or dual space layer). |
| B | Connected nodes or connected cells shall be consistent with connected layers. It means that the target cell spaces (or nodes) shall belong to primal space layer (or dual space layer) of the connected layer. |
| C | The cardinalities of Node and CellSpace can either be 0 or 2, but can never be 1. |
Annex A
(normative)
Conformance Class Abstract Test Suite
A.1. Introduction
This normative annex specifies the test suite, which will be used for the conformance test of OGC IndoorGML 2.0 Part I. As OGC IndoorGML 2.0 Part I is a conceptual model, this test suite is an abstract one and its executable test suite shall depend on the implementation of OGC IndoorGML 2.0 Part I, more precisely the encoding system of OGC IndoorGML 2.0 such as XML, JSON, or SQL.
A.2. General Tests
Since OGC IndoorGML 2 is based on ISO 19103:2015, ISO 19107:2019, ISO 19109:2015, ISO 19110:2016, and ISO 19111:2019, the abstract tests of these precedent standards shall be applied to OGC IndoorGML 2.
A.3. UML Common Tests
Requirements class A.1 | |
|---|---|
| Identifier | http://www.opengis.net/spec/indoorgml/2.0/req/common |
| Target type | Implementation Specification |
| Conformance class | Conformance class A.1: http://www.opengis.net/spec/indoorgml/2.0/conf/common |
| Normative statements | Requirement A.1: /req/common/cardinalities Requirement A.2: /req/common/properties Requirement A.3: /req/common/codelist |
Conformance class A.1 | |
|---|---|
| Identifier | http://www.opengis.net/spec/indoorgml/2.0/conf/common |
| Requirements class | Requirements class A.1: http://www.opengis.net/spec/indoorgml/2.0/req/common |
| Target Type | Implementation Specification |
| Conformance tests | Abstract test A.1: /conf/common/cardinalities Abstract test A.2: /conf/common/properties Abstract test A.3: /conf/common/codelist |
A.3.1. Cardinalities
Requirement A.1 | |
|---|---|
| Identifier | /req/common/cardinalities |
| Included in | Requirements class A.1: http://www.opengis.net/spec/indoorgml/2.0/req/common |
| A | The cardinalities defined in the UML diagrams in the core and navigation modules shall be correctly applied to any implementation of IndoorGML 2. |
Abstract test A.1 | |
|---|---|
| Identifier | /conf/common/cardinalities |
| Requirement | Requirement A.1: /req/common/cardinalities |
| Test method | Manual or automated inspection |
A.3.2. Properties
Requirement A.2 | |
|---|---|
| Identifier | /req/common/properties |
| Included in | Requirements class A.1: http://www.opengis.net/spec/indoorgml/2.0/req/common |
| A | The properties of classes defined in the UML diagrams in the core and navigation modules shall be correctly applied to any implementation of IndoorGML 2. |
Abstract test A.2 | |
|---|---|
| Identifier | /conf/common/properties |
| Requirement | Requirement A.2: /req/common/properties |
| Test method | Manual or automated inspection |
A.3.3. Code List
Requirement A.3 | |
|---|---|
| Identifier | /req/common/codelist |
| Included in | Requirements class A.1: http://www.opengis.net/spec/indoorgml/2.0/req/common |
| A | The value of class properties shall be in the code list if the value type is defined as an enumeration in the UML diagrams in the core and navigation modules of IndoorGML 2. |
Abstract test A.3 | |
|---|---|
| Identifier | /conf/common/codelist |
| Requirement | Requirement A.3: /req/common/codelist |
| Test method | Manual or automated inspection |
A.4. Conformance Class Core
Conformance class A.2 | |
|---|---|
| Identifier | http://www.opengis.net/spec/indoorgml/2.0/conf/core |
| Requirements class | Requirements class 1: http://www.opengis.net/spec/indoorgml/2.0/req/core |
| Target Type | Implementation Specification |
| Conformance tests | Abstract test A.4: /conf/core/thematiclayer Abstract test A.5: /conf/core/cellspace Abstract test A.6: /conf/core/cellboundary Abstract test A.7: /conf/core/node Abstract test A.8: /conf/core/edge Abstract test A.9: /conf/core/interlayerconnection |
A.4.1. Class ThematicLayer
Abstract test A.4 | |
|---|---|
| Identifier | /conf/core/thematiclayer |
| Requirement | Requirement 1: /req/core/thematiclayer |
| Test method | Manual or automated inspection |
A.4.2. Class CellSpace
Abstract test A.5 | |
|---|---|
| Identifier | /conf/core/cellspace |
| Requirement | Requirement 2: /req/core/cellspace |
| Test method | Automated inspection by geometric computation |
A.4.3. Class CellBoundary
Abstract test A.6 | |
|---|---|
| Identifier | /conf/core/cellboundary |
| Requirement | Requirement 3: /req/core/cellboundary |
| Test method | Automated inspection by geometric computation |
A.4.4. Class Node
Abstract test A.7 | |
|---|---|
| Identifier | /conf/core/node |
| Requirement | Requirement 4: /req/core/node |
| Test method | Automated inspection by geometric computation |
A.4.5. Class Edge
Abstract test A.8 | |
|---|---|
| Identifier | /conf/core/edge |
| Requirement | Requirement 5: /req/core/edge |
| Test method | Automated inspection by geometric computation |
A.4.6. Class InterLayerConnection
Abstract test A.9 | |
|---|---|
| Identifier | /conf/core/interlayerconnection |
| Requirement | Requirement 6: /req/core/interlayerconnection |
| Test method | Automated inspection by geometric computation |
Bibliography
[1] Apple Inc.: OGC 20-094, Indoor Mapping Data Format. Open Geospatial Consortium (2021).
[2] Policy SWG: OGC 08-131r3, The Specification Model — Standard for Modular specifications. Open Geospatial Consortium (2009).
[3] Gerhard Gröger, Thomas H. Kolbe, Claus Nagel, Karl-Heinz Häfele: OGC 12-019, OGC City Geography Markup Language (CityGML) Encoding Standard. Open Geospatial Consortium (2012). http://www.opengis.net/spec/citygml/2.0.
[4] David Burggraf: OGC 12-007r2, OGC KML 2.3. Open Geospatial Consortium (2015). http://www.opengis.net/doc/IS/kml/2.3.
[5] Jiyeong Lee, Ki-Joune Li, Sisi Zlatanova, Thomas H. Kolbe, Claus Nagel, Thomas Becker, Hye-Young Kan: OGC 19-011r4, OGC® IndoorGML 1.1. Open Geospatial Consortium (2020). http://www.opengis.net/doc/IS/indoorgml/1.1.
[6] ISO: ISO 16739-1, Industry Foundation Classes (IFC) for data sharing in the construction and facility management industries. International Organization for Standardization, Geneva https://www.iso.org/standard/70303.html.
[7] ISO: ISO 19152, Geographic information. International Organization for Standardization, Geneva https://www.iso.org/standard/51206.html.
[8] Princeton University.: WordNet, https://wordnet.princeton.edu/
[9] Yan, J., Diakité, A. A., Zlatanova, S.: A generic space definition framework to support seamless indoor/outdoor navigation systems. Transactions in GIS, 23, 6, 1273-1295 (2019)
[10] Zlatanova, S., Yan, J., Wang, Y., Diakité, A., Isikdag, U., Sithole, G., Barton, J.: Spaces in Spatial Science and Urban Applications—State of the Art Review. ISPRS International Journal of Geoinformation, 9, 1, 58 (2020)
[11] Alattas, A., Zlatanova, S., Van Oosterom, P., Chatzinikolaou, E., Lemmen, C., Li, K. J.: Supporting Indoor Navigation Using Access Rights to Spaces Based on Combined Use of IndoorGML and LADM Models. ISPRS International Journal of Geoinformation. 6, 12, 384 (2017)
[12] Diakité, A. A., Zlatanova, S.: Spatial subdivision of complex indoor environments for 3D indoor navigation. International Journal of Geographical Information Science. 32, 2, 213-235 (2018)
[13] Egenhofer M.J.: A formal definition of binary topological relationships. In: Litwin W., Schek HJ. (eds) Foundations of Data Organization and Algorithms, FODO 1989, Lecture Notes in Computer Science. 367, 457–472 (1989)
[14] Gröger, G., B. George: Geometry and Topology. In: Kresse, W., Danko, D. (eds) Springer Handbook of Geographic Information. 303-321 (2012)
[15] Morris, S.: Topology Without Tears, http://www.topologywithouttears.net/topbook2023.pdf
[16] Munkres, J. R.: Elements Of Algebraic Topology (1st ed.). CRC Press. https://doi.org/10.1201/9780429493911 (1984)
[17] Lee, J.: A spatial access-oriented implementation of a 3D GIS topological data model for urban entities. GeoInformatica, 8, 237-264 (2004)